REMARKS 

Please reconsider the claims in the application in view of the remarks below. 
Claim Rejection - 35 U.S.C §103 

Claims 1, 2, 12-15, 25, 26 and 33 stand rejected under 35 U.S.C. §103(a) as allegedly 
being unpatentable over U.S. Patent No. 6.405,315 ("Bums") in view of U.S. Patent No. 
6,959,384 ("Serret-Avila"). The Office Action rejected claims 3, 7-8, 10, 11, 20, 21, 23, 24, 27, 
29-32 under 35 U.S.C. § 1 03(a) as allegedly being unpatentable over Bums in view of Serret- 
Avila and further in view of U.S. Patent No. 6,931,543 ("Pang"), in view of U.S. Patent No 
5,124,1 17 ("Tatebayashi"). Claims 4, 17 were rejected under 35 U.S.C. §103(a) as allegedly 
being unpatentable over Bums and Serret-Avila in view of U.S. Patent No. 5,608,801 ("Aiello"). 
Of the pending claims, claims 1, 14, 25 and 33 are independent. 

In responding to the applicant's previous arguments that Bums and Serret-Avila do not 
disclose or suggest storing integrity tree data stmcture at the client and that the root data structure 
is not written out to the storage device, the Examiner cites Serret-Avila's Col. 8, lines 46-69 and 
Col. 14, lines 59-64 as allegedly disclosing those elements. Serret-Avila as understood by 
applicant discloses a receiver authenticating the stream data that is sent firom the sender and 
received at the receiver. Serret-Avila's sender encodes the stream data, then sends the encoded 
data and the corresponding signature or check values to the receiver. Serret-Avila's receiver 
receives the data and signature or check values to decode and authenticate the data. Serret-Avila 
thus as understood by applicant discloses exchanging of the signature or check values between 
the sender and receiver. Whenever Serret-Avila methodology sends the encoded data, the 
signature or check values are also sent together with the encoded data. A receiver that receives 
the encoded data and the signature or check values verifies using the received signature or check 
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values the authenticity of the encoded data. In another words, Serret-Avila's encoded data and 
the signature (or check) values travel together. Unlike the Examiner's interpretation, Serret- 
Avila does not disclose or suggest that its signature or check values are kept only with the sender 
that encodes the data while the encoded data is sent to another device. 

In Response to Arguments on page 2 of the Office Action, the Examiner also alleges, 
"Applicant is referring to the alternative embodiment where the check values are transmitted 
(and/or transmission). Applicant has chosen to ignore the very clear fact that Serret- Avila 
specifically discloses that the check valu^ can be stored without transmission." Contrarily, 
appHcant has not ignored that Serret-Avila's statement in Col. 8, lines 46-69 and Col. 14, lines 
59-64 that the check values are "saved for later use and/or transmission." Rather, appHcant is 
averring that even though Serret- Avila sav^ for later use, that later use is for transmission with 
the encoded data. If Serret-Avila's check value is not transmitted with the encoded data, it 
would defeat the whole purpose of Serret- Avila that discloses the method for an encoder to send 
the encoded data and the check value to a decoder that receives the encoded data together with 
the check value for performing the authenticity check. Thus, Serret-Avila's method would not 
work if only the encoded data was sent without the check value, i.e., the check value is kept with 
the sender only. 

It is also not clear what alternative embodiments the Examiner's referring to because as 
understood by applicant, all of Serret-Avila's embodiments describe sending encoded data with 
the check value. For example, one embodiment that refers to the encoding and exchange of the 
encoded data between the sender and the receiver described with reference to Figs. 3-8 explicitly 
discloses, "To transfer data block 400 to a recipient 204, encoding system 202 first sends 
S(H(Cj)) 424, the sub-block to which S(H(Ci)) 424 corresponds (i.e.. Pi 425), and check value 
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H(C2) 421, Encoding system 202 then continues to send successive sub-blocks, Pj, and check 
values, H(Ci+i)~moving left to right in FIG. 4~until the entire file has been transmitted." Col. 
10, lines 16-27 explicitly describe how the received block of data is used to calculate check 
values and compared to the received check values for authenticating. Another embodiment 
described with reference to Fig. 9, et seq. and that refers to a process for encoding data in a 
manner designed to facilitate efficient and secure content navigation also requires that the 
encoded data be sent along with the check value to a user. That is, Col. 1 5, lines 7-10 exphcitly 
require that "the user first obtains the content file and its corresponding signature and hash tree. . . 
the user's system may receive these data from network 203 or a disc 280 inserted into disc drive 
258." Thus, even in this embodiment, the user's system must receive both the data and the 
relevant check value in order for the Avila-Serret's authentication method to work. 

The Examiner further alleges that applicant's assertion that Avila-Serret's method would 
not work if its check values were only kept with the sender is "wholly unsupported by any 
evidence." Again, contrarily, applicant has painstakingly explained why Avila-Serret's method 
would not work. That is, Serret-Avila's method is to convey the encoded data together with the 
check values for the receiver to authenticate the data received from the sender. A person of 
ordinary skill in the art from reading Serret-Avila would clearly understand that Serret-Avila's 
method would not work without sending the corresponding check value together with the 
encoded data to the receiver. Otherwise, how would Serret-Avila perform its authentication? 

On the other hand, independent claims 1, 14, 25 and 33 recite, "data blocks are written 
out to the network-attached storage device, ... a root data structure for protecting integrity of all 
content written to said storage device, . . . wherein the root structure is not written out to the 
storage device." 
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For at least the above reasons. Bums and Serret-Avila even if combined fail to disclose or 
suggest every element claimed in independent claims 1, 14, 25 and 33, and the Examiner has 
failed to make a prima facie case of obviomness. Applicants believe that independent claims 1, 
14, 25 and 33, and their respective dependent claims at least by virtue of their dependency are 
not obvious over Bums and Serret-Avila. 

With respect to the dependent claims rejected also in view of the rest of the references, 
because those references fail to disclose or suggest what Bums and Serret-Avila lack as 
explained above with respect to independent claims, those dependent claims also are believed to 
be unobvious over the cited references. 

hi view of the foregoing, this application is now believed to be in condition for 
allowance, and a Notice of Allowance is respectfully requested. If the Examiner believes a 
telephone conference might expedite prosecution of this case, applicant respectfiilly requests that 
the Examiner call applicant's attorney at (516) 742-4343. 

Respectfully submitted, 

. 

Eunhee Park 
Registration No.: 42, 976 

Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, N.Y. 11530 
(516) 742-4343 
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